Note to self:

• We wanted to do this originally in 2023 but had to revert due to a tree-sitter bug, see Narrow search range for tree-sitter queries #1769
• At some point that got fixed, query.matches function ignores top-level wildcard nodes when determining whether to include match tree-sitter/tree-sitter#2484 was closed a few weeks ago
• This reintroduces the logic to specify a document text range when querying
• For containing or iteration scope you get the greatest possible benefit because we know exactly the range we need for the containing scope and it will likely be quite small compared to the document size
  • (NB: smearing by one character exactly is pretty nifty)
• This change also introduces a second optimization: if not using a containing scope, only searching forward or backwards, rather than the entire document since many expensive queries are often directional ("take next funk" without an iteration scope for example).

Possible future direction: We could make querying more incremental so it doesn't lock up with a gigantic query, but that's tricky because we don't necessarily know the tradeoff point. Multiple queries could be slower overall.

Some of this is limited by the fact that the actual grammar allows you to select an infinite amount of targets if you ask for it. So there's some limit to what we can do. We discussed the idea of a configuration default limit, but it's pretty hazy. I seem to recall least one person running into a problem where VS Code became extremely laggy after they accidentally asked for hundreds of thousands of selections. OTOH it's conceivable you could want to use this to do a gigantic refactor across the whole file?